[% setvar title The Perl 6 Summary for the week ending 20030406 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030406'></a><h1>The Perl 6 Summary for the week ending 20030406</h1>
<p>Welcome my friends to the show that never ends. Yes, it's another of
Piers Cawley's risible attempts to summarize the week's happenings in
the Perl 6 development community. We start, as usual, with events in
the perl6-internals world (not the perk6-internals world, obviously,
that would be the sort of foolish typo that would <i>never</i> make it
into any mail sent to the Perl 6 lists) where things have been
quiet... too quiet. I think they're planning something.</p>
<a name='Documentation for PMCs'></a><h2>Documentation for PMCs</h2>
<p>Alberto Simoes posted some documentation for the Array PMC and
suggested somewhere for it to be included in the Parrot
distribution.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=21759' target='_blank'>rt.perl.org</a></p>
<a name='Extension PMC vs built-in'></a><h2>Extension PMC vs built-in</h2>
<p>K. Stol asked how to go about creating extension PMCs which he could
use without having to recompile the entire Parrot VM. No answers yet.</p>
<p><a href='http://groups.google.com/groups?threadm=BAY1-DAV32Zm8PYhu5M0004976d@hotmail.com' target='_blank'>groups.google.com</a></p>
<a name='Documentation problem with set_global'></a><h2>Documentation problem with <code>set_global</code></h2>
<p>K Stol reported a problem with <b><i>parrot_assembly.pod</i></b>, apparently
there was a disagreement between the docs and the code about
<code>set_global</code>. Leopold T&ouml;tsch agreed that this was a
documentation bug, but pointed out that it was far from being the only
one. He suggested that <b><i>parrot_assembly.pod</i></b> should only have a
general description of Parrot Assembly, with details of 'real' ops in
generated docs like <b><i>core_ops.pod</i></b> and information on as yet
unimplemented in the appropriate PDDs.</p>
<p><a href='http://groups.google.com/groups?threadm=BAY1-DAV14WV13OEmRZ0004cb72@hotmail.com' target='_blank'>groups.google.com</a></p>
<a name='Building IMCC in Win32'></a><h2>Building IMCC in Win32</h2>
<p>Clinton A Pierce's work last week to get IMCC building in a Win32
environment was admired by Leo T&ouml;tsch, who promised to check the
needed patches into the distribution.</p>
<p><a href='http://groups.google.com/groups?threadm=3E8ABD27.4080805@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Typos in rx.ops'></a><h2>Typos in <b><i>rx.ops</i></b></h2>
<p>Cal Henderson submitted a patch to fix some typos in <b><i>rx.ops</i></b>, which
were applied. Anton Berezin sent in a further patch to fix a few more
errors.</p>
<p><a href='http://groups.google.com/groups?threadm=20030403065455.729626C1CB@neuron.neuron1.com' target='_blank'>groups.google.com</a></p>
<a name='Parrot regex engine'></a><h2>Parrot regex engine</h2>
<p>Benjamin Goldberg praised <b><i>rx.ops</i></b>, commenting that he was 'amazed at
how cool it is' and wondered if the work was based on something
else. Steve Fink thought it was original to Brent Dax. Steve also
pointed to an unfinished draft of his detailed description of how at
least one of Parrot's regex implementations works.</p>
<p><a href='http://groups.google.com/groups?threadm=3E8CF2B2.76AB1170@earthlink.net' target='_blank'>groups.google.com</a></p>
<p><a href='http://0xdeadbeef.net/~sfink/uploads/regex.pod' target='_blank'>0xdeadbeef.net</a> -- Steve Fink's
description</p>
<a name='Dan Explains Everything'></a><h2>Dan Explains Everything</h2>
<p>Away from the internals list, Dan Sugalski has been doing some
fascinating brain dumps about the 'whys' of Parrot in his weblog
'Squawks of the Parrot'. Specifically, he's been addressing why JVM
and .NET weren't chosen. In the course of this discussion he's come up
with a rather neat one sentence description of continuations: &quot;A
continuation is essentially a closure that, in addition to closing
over the lexical environment, also closes over the control chain.&quot;</p>
<p>Anyway, I commend the whole blog to you.</p>
<p><a href='http://www.sidhe.org/~dan/blog/' target='_blank'>www.sidhe.org</a></p>
<a name='Meanwhile over in perl6-language'></a><h1>Meanwhile over in perl6-language</h1>
<p>The perl6-language list was where all the action was this week with
the list attracting far more traffic than the internals list at the
moment.</p>
<a name='How shall threads work in P6?'></a><h2>How shall threads work in P6?</h2>
<p>Austin Hastings has 'been thinking about closures, continuations, and
coroutines, and one of the interfering points has been threads.'
Austin wants to know what the Perl 6 threading model will look like,
and threw out a few suggestions. Matthijs van Duin thought that
preemptive threading in the core would be unnecessary, arguing that
cooperative threading would solve everyone's problems. Almost nobody
agreed with him. Most tellingly, Dan disagreed with him. Parrot will
be getting preemptive threads and that's not a point for negotiation.</p>
<p>Larry popped up to point out that, at the language level, the
underlying thread implementation (whether preemptive or cooperative)
really didn't matter, what was more important to the user was how much
information was shared between threads. Larry said he thought that
both the pthreads (all globals shared by default) and ithreads (all
globals unshared by default) approaches to threading were 'wrong to
some extent'.</p>
<p><a href='http://groups.google.com/groups?threadm=20030331154530.4491.qmail@web12307.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030404191304.GB28950@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Conditional returnss?'></a><h2>Conditional <code>returns</code>s?</h2>
<p>Michael Lazzaro was concerned about the inefficiency of</p>
<pre>    return result_of_big_long_calculation(...) 
        if result_of_big_long_calculation(...);</pre>
<p>and ugliness of:</p>
<pre>    my $x = result_of_big_long_calculation(...);
    return $x if $x;</pre>
<p>He wondered if there was a less ugly way to do it in Perl 6. There is:</p>
<pre>    given result_of_big_long_calculation(...) { return $_ when true }</pre>
<p>was the most popular solution, but Dave Whipp pointed out that it
would also be possible to write:</p>
<pre>    sub return_if_true ($value) {
        if $value {
            leave where =&gt; caller(1), value =&gt; $value;
        }
    }</pre>
<p>and then just do:</p>
<pre>    return_if_true(result_of_big_long_calculation(...));</pre>
<p>You know, I like Perl 6 more and more.</p>
<p><a href='http://groups.google.com/groups?threadm=9CCFB386-63AB-11D7-9C90-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='== vs. eq'></a><h2>== vs. eq</h2>
<p>Luke Palmer wondered if there was anything to be gained by getting rid
of the distinction between <code>==</code> and <code>eq</code> and falling back to a
polymorphic <code>==</code>. Brent Dax pointed out that the <code>~~</code> 'smartmatch'
operator did exactly that. Luke said that <code>~~</code> didn't meet his
needs (its behaviour with hashes, for instance, isn't what you want
when trying to find out if two hashes are equal). Smylers pointed out
that Larry had already rejected (and had given good reasons why) the
idea. Luke still wanted a 'generic equality' operator though. Marco
Baringer threw a spanner in the works by pointing out that no such
thing as 'generic equality' exists. Luke also came up with a symbol for
an identity operator, <code>=:=</code> defined as:</p>
<pre>    sub operator:=:= ( $a, $b ) { $a.id == $b.id }</pre>
<p>Michael Lazzaro isn't convinced of the need for a universal .id
method, but he does like the idea of an identity test operator. There
was then some discussion of</p>
<pre>    \@a == \@b;</pre>
<p>which, Michael claims would compare the lengths of <code>@a</code> and <code>@b</code>
rather than their addresses. He backed this up with a quote from Larry
where he said &quot;But it's probably fair to say that $foo and @foo always
behave identically in a scalar context&quot;. I think Michael's wrong
because <code>\@a</code> is not the same as <code>$a</code>. By his argument it seems that
even</p>
<pre>    my $array_ref = \@foo;
    my $ary_ref2  = [1, 2, 3];</pre>
<p>won't work, which seems wrong somehow.</p>
<p>Discussion continued with various different possible implementations
of 'generic' equality operators thrown up for consideration. One
subthread even saw the return of Tom &quot;I thought he'd got a life and
left the Perl community&quot; Christiansen in a thread that ended up
talking about transfinite numbers and the cardinality of infinite
sets (which was interesting, but rather beside the point). Andy
Wardley got bonus points for making me laugh: &quot;G&ouml;del seems to think
there is an answer, but he doesn't know what it is. Turing is trying
to work it out on a piece of paper, but he can't say when (or if)
he'll be finished.&quot; Okay, it may not make you laugh, but my degree is
in maths.</p>
<p><a href='http://groups.google.com/groups?threadm=ygc3cl3uhf4.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?hl=en' target='_blank'>groups.google.com</a>&amp;lr=&amp;ie=UTF-8&amp;selm=sfwr8r0uf8o.fsf@shell01.TheWorld.com -- Why generic equality doesn't exist</p>
<a name='is is overoverloaded?'></a><h2><code>is</code> is overoverloaded?</h2>
<p>Luke Palmer was concerned that <code>is</code> has too many meanings. It gets
used for setting variable traits, defining base classes and setting up
tied variables. Luke is concerned that these appear to be too varied
in meaning, and proposed at least adding a new <code>isa</code> keyword for
defining base classes. There was some discussion, but I'm not sure
that either side is convinced of the other's rectitude.</p>
<p><a href='http://groups.google.com/groups?threadm=20030401015656.B091A52@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Short-circuiting user-defined operators'></a><h2>Short-circuiting user-defined operators</h2>
<p>Joe Gottman wondered if there would be a way to write an operator
which would short circuit in the same way as <code>&amp;&amp;</code> and <code>||</code>. He
wondered if this would be a function trait (suggesting <code>is
short_circuit</code>), or something cunning to do with parameters. Larry
thought Joe was trying too hard, proposing:</p>
<pre>    sub infix:!! ($lhs, &amp;rhs) is equiv(&amp;infix:||) {...}</pre>
<p>He noted that if that couldn't be made to work you might have to
declare the operator as a macro, but that it still shouldn't be too
hard to implement. Dave Whipp wasn't too sure about Larry's assertion
that declaring a parameter as <code>&amp;foo</code> should force the RHS of that
operator to be a closure. What, he wondered would happen with <code>10 !!
&amp;closure</code>?</p>
<p><a href='http://groups.google.com/groups?threadm=007501c2f8b6$e8795fc0$cf6e1918@carolina.rr.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030405184012.GA5104@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Ruminating RFC 93 - alphabet-blind pattern matching'></a><h2>Ruminating RFC 93 - alphabet-blind pattern matching</h2>
<p>Yary Hluchan has been reading the Perl 6 RFC 93, which Larry discussed
in Apocalypse 5 and discussed doing regular expression type matches on
streams of 'things', where the things weren't necessarily Unicode
characters. At one point though Larry popped up to say that the
discussion seemed to run contrary to what he said about RFC 93 in
Apocalypse 5.</p>
<p>Further down the thread, Ed Peschko wondered about using the Regex
engine 'in reverse' to generate a list of all the possible strings
that a regular expression could match. Everyone politely assumed that
when Ed referred to the rule <code>rx/a*/</code> he really meant <code>rx/^a*$/</code> and
got stuck into the problem. Matthijs van Duin pointed out that to get
a 'useful' list of productions you'd have to go about producing all
possible matches of length 'n' before giving any possibilities of
length n+1 (where 'length' counts atoms I think...). Once Luke Palmer
had that key insight he showed off an implementation that could
generate such a list. Piers Cawley used Luke's cunning implementation
to show a lazy <code>generate_all</code> method that would iterate through all
the possible productions of a rule. Luke said that he hoped it
wouldn't actually need such a wrapper to be lazy. Personally I think
that might be a hope too far...</p>
<p><a href='http://groups.google.com/groups?threadm=200304020627.h326RKb21625@bell.apicom.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=ygcy92rv7ga.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a> -- Luke's code, with
explication further down the thread</p>
<a name='Named vs. Variadic Parameters'></a><h2>Named vs. Variadic Parameters</h2>
<p>This thread continued from last week. The problem is that, if you want
to define a function that you would call in the following fashion:</p>
<pre>    foo $pos, opt_nam =&gt; 'value', 'slurpy', 'list', ...;</pre>
<p>Then your signature needs to look like</p>
<pre>    sub foo ( $pos, *@slurpy, +$opt_nam ) {...}</pre>
<p>which seems rather counter intuitive (though mixing positional and non
positional parameters could be seen to be counter intuitive whatever
happens...) Various people argued for longer forms to denote the
differences between positional, named, optional etc arguments and
proposed various solutions. Larry didn't sound all that convinced,
pointing out that if you wanted to implement such parameter
specification styles you could always use a macro and declared that
&quot;Perl 6 is designed to allow cultural experimentation.  You may
reclassify any part of Perl 6 as a bike shed, and try to persuade
other people to accept your taste in color schemes.  Survival of the
prettiest, and all that...&quot;</p>
<p><a href='http://groups.google.com/groups?threadm=20030402113533.A64627@megazone.bigpanda.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030404184049.GA28950@wall.org' target='_blank'>groups.google.com</a></p>
<a name='Implicit threading'></a><h2>Implicit threading</h2>
<p>The discussion of how to write short circuiting operators spawned a
subthread (which, rather annoyingly shared the same subject...)
trigged by a suggestion of David Whipp's to do lazy initialization of
some variables by spawning subthreads. The idea being that one could
do</p>
<pre>   my $a is lazy := expensive_fn(...);</pre>
<p>or something, and Perl would immediately spawn a subthread to
calculate the value of <code>expensive_fn(...)</code> then, at the point you
come to use the value of <code>$a</code>, the main thread would do a thread join
and block if the subthread hadn't finished. Austin Hastings liked the
idea and went on to suggest other places in which implicit threading
could be used. My gut feeling is that this is the sort of thing that
will get implemented in a module on top of whatever explicit threading
system we get in Perl 6.</p>
<p><a href='http://groups.google.com/groups?threadm=20030402015704.25392.qmail@onion.perl.org' target='_blank'>groups.google.com</a> -- Dave Whipp's cunning
idea</p>
<p><a href='http://groups.google.com/groups?threadm=20030403170325.26461.qmail@web12308.mail.yahoo.com' target='_blank'>groups.google.com</a> -- Further
discussion here</p>
<a name='Properties and Methods'></a><h2>Properties and Methods</h2>
<p>Luke Palmer was concerned about potential naming clashes between
properties and methods. He thought that things would be safer if,
instead of accessing properties using method call type syntax. He was
also worried about method naming clashes between the methods of things
in a junction, and of the Junction class itself. Nobody had commented
on this by the end of the week.</p>
<p><a href='http://groups.google.com/groups?threadm=ygche9fqut2.fsf@babylonia.flatirons.org' target='_blank'>groups.google.com</a></p>
<a name='Patterns and Junctions'></a><h2>Patterns and Junctions</h2>
<p>Adam D. Lopresto had a suggestion for using two different kinds of
alternation in regular expressions. In Adam's proposal, alternation
with <code>|</code> could ignore the order of the alternatives when attempting
to make a match and alternation with <code>||</code> would do the kind of order
respecting alternation we're used to. I confess that I wondered what
on earth Adam was on about, but Luke Palmer liked the idea, pointing
out a way something like it could be used for globally optimizing
large grammars. However, he was unconvinced by the syntax and
suggested that it would be better if we could mark rules as being
'side effect free' and thus capable of being run in arbitrary order.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.GSO.4.53.0304030832230.5753@ritz.cec.wustl.edu' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>The schedules for both OSCON and YAPC::USA have been announced and
there's a fair amount of Perl 6 and Parrot related content at both of
them. I shall be attending both conferences (but only speaking at YAPC
-- about refactoring tools and about Pixie; the object persistence
tool I work on, neither of which are Perl 6 related) and driving from
YAPC to OSCON with probable stops in Washington DC, Philadelphia,
Boston, Burlington VT, Ottawa and Chicago (where we cheat and hop on a
train). Hopefully I'll get to meet up with some of my happy readers at
some or all of these stops and at the conferences.</p>
<p><a href='http://www.yapc.org/America/' target='_blank'>www.yapc.org</a> -- YAPC</p>
<p><a href='http://conferences.oreillynet.com/os2003/' target='_blank'>conferences.oreillynet.com</a> -- OSCON</p>
<p>I would like to apologize to Leon Brocard for failing to mention
his name in this week's summary. Leon is offering a 'Little Languages in
Parrot' talk at OSCON though.</p>
<p>If you've appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or a few pounds of www.puttyworld.com's products to p6summarizer@bofh.org.uk'></a>Send feedback, flames, money, photographic and writing commissions, or
a few pounds of <a href='http://www.puttyworld.com' target='_blank'>www.puttyworld.com</a>'s products to
<i><a href='http://search.cpan.org/perldoc?p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a></i></li>
</ul>
<p>This week's summary was again sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></p>
</div>
